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SYSTEM AND METHOD FOR FACILITATING ACCESS BY SELLERS TO 
CERTIFICATE-RELATED AND OTHER SERVICES 



This application claims priority to United States provisional patent application serial 
No. 60/153,302, filed September 10, 1999, entitled System and Process for Certification in 
Electronic Commerce, United States provisional patent application serial No. 60/153,328, 
filed September 10, 1999, entitled System and Process for Certification in Electronic 
Commerce, and United States provisional patent application serial No. 60/153,723, filed 
September 13, 1999, entitled Pilot Web Application and Software Development Kit 
Architecture, all three of which are hereby incorporated by reference. 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document contains material which is 
subject to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it appears in the 
Patent and Trademark Office patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates generally to the field of facilitating electronic commerce by 
providing services via a public key infrastructure. 

BACKGROUND OF THE INVENTION 

The world of electronic commerce has created new challenges to establishing 
relationships between contracting parties. One of those challenges springs from the fact 
that the parties to the transaction cannot see or hear each other, and cannot otherwise easily 
confirm each other's identity and authority to act. 

One remedy for this problem is to provide each contracting party with a private key 
for signing transmitted messages. The signing party makes available an associated public 
key that decrypts messages signed with the party's private key, and thus enables a receiving 
party to confirm the identity of the sender. 

But the sender's public key may not be known a priori to the recipient. In that 
event, the sender may transmit with its signed message a digital certificate issued by a 
certificate authority. The certificate is itself a signed electronic document (signed with the 



private key of the certificate authority) certifying that a particular public key is the public 
key of the sender. 

In some cases, the recipient may be unfamiliar with the public key of the certificate 
authority or may not know whether the certificate is still valid. In that event, the recipient 
may wish to check the authenticity and validity of the certificate with an entity that it trusts. 
One known protocol for checking certificate status is the on-line certificate status protocol 
(OCSP). 

SUMMARY OF THE INVENTION 

A system and method are disclosed for facilitating access to a plurality of 
certificate-related and other services including certificate validation. In a preferred 
embodiment, these services are provided within the context of a four-corner trust model. 
The four-corner model comprises a buyer, also referred to as the subscribing customer, and 
a seller, also referred to as the relying customer, who engage in an on-line transaction. 

The buyer is a customer of a first financial institution, referred to as an issuing 
participant. The issuing participant acts as a certificate authority for the buyer and issues 
the buyer a hardware token including a private key and a digital certificate signed by the 
issuing participant. The seller is a customer of a second financial institution, referred to as 
the relying participant. The relying participant acts as a certificate authority for the seller 
and issues the seller a hardware token including a private key and a digital certificate signed 
by the relying participant. The system also includes a root certificate authority that issues 
digital certificates to the issuing and relying participants. 

At the time of a transaction, the buyer creates a hash of the transaction data, signs 
the hash, and transmits the transaction data, the signature, and its digital certificate to the 
seller. The seller may then request system services such as certificate validation from its 
financial institution, the relying participant. 

The present system and method provide the seller with digital signature messaging 
software for accessing these system services. Two preferred implementations are disclosed 
for integrating a seller's existing Web server and applications with this software and, more 
generally, with the public key infrastructure described below. 

The first preferred implementation is referred to as "passive integration" because it 
requires no modification to a seller's existing e-commerce Web application. This 
implementation is designed for organizations seeking the least complex and least intrusive 
method of integrating their existing Web server with the computer systems of other entities 
in the four-corner model. 



In this first implementation, the seller's Web site is preferably provided with five 
additional components: a Web filter, a second Web server, a servlet, a filter engine, and a 
bank interface. The Web filter redirects all requests received by the seller's Web site from 
the seller's existing Web application to the second Web server. The second Web server 

5 parses the request and forwards it to the servlet. The servlet accepts connections, runs 
applications based on the requested URL, and parses the connections to the filter engine. 
The filter engine identifies pages from the buyer that require the buyer's signature, formats 
the data from such pages for signature, and returns the data to the servlet with instructions 
to have the data signed by the buyer. The servlet generates a response to the buyer's 

10 browser that requests signature of the formatted data. The buyer signs the formatted data 
and returns it to the seller. 

The signed data is forwarded to the seller's bank interface which generates a signed 
request for service, and transmits the request to the seller's relying participant. When, for 
example, the requested service is certificate validation, the bank interface generates an 

15 OCSP request for transmission to the seller's relying participant. The relying participant 
processes the request and returns a response to the seller's bank interface. 

Passive integration may be preferred by sellers having small computer staffs 
because it is less time consuming to implement, although less efficient. Minimal 
knowledge of a seller's existing e-commerce applications and core technologies is required 

2Q to successfully integrate the seller's Web site with other system components. Little or no 
modification of e-commerce application source code is required. 

The second preferred embodiment is referred to as "active integration" because it 
requires the seller to rewrite code of its Web applications to provide the functionality 
necessary to access system services. In active integration, the seller's Web site is 

25 preferably provided with the bank interface described above but the functionality provided 
by the other digital signature messaging software components is instead provided by 
modifying directly the seller's Web application. 

Active integration may be preferred by advanced organizations looking for 
complete integration with existing applications. Access to the seller's e-commerce 

30 application source code and a computer staff with a strong technical background are 
typically required for active integration. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The above summary of the invention will be better understood when taken in 
35 conjunction with the following detailed description and accompanying drawings, in which: 
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Fig. 1 is a block diagram of a preferred embodiment of the four-corner model 
employed by the present system; 

Fig. 2 is a block diagram depicting components preferably provided at entities in the 
four-corner model; 

5 Fig. 3 is a block diagram of a preferred embodiment for passively integrating digital 

signature messaging software with a seller's existing Web application; 

Fig. 4 shows sample code suitable for implementing filter 302 of Fig. 3; 

Fig. 5 is an example of servlet 304 process flow in a preferred embodiment; 

Fig. 6 is an exemplary format of a rules file for filter engine 306 in a preferred 
embodiment; 

Fig. 7 illustrates sample code that may be used in a preferred embodiment to invoke 
the filter engine RMI server; 

Fig. 8 illustrates a preferred embodiment of the steps invoked when filter engine 
306's RMI server is started; 
j 5 Fig. 9 illustrates a preferred embodiment of the steps invoked when servlet 304 

sends a request to filter engine 306; 

Fig. 10 illustrates a preferred embodiment for implementing bank interface 222; 

Fig. 1 1 illustrates a preferred embodiment of the steps invoked when the RMI server 
of bank interface 222 is started; 
20 Fig. 12 illustrates the steps invoked when filter engine 306 sends a request to bank 

interface 222 in a preferred embodiment; 

Fig. 13 illustrates an example of system operation using passive integration; 

Fig. 14 is a block diagram of a preferred architecture for actively integrating digital 
signature messaging software with a seller's existing Web application; 
25 Fig. 15 illustrates an example of system operation using active integration. 

Fig. 16 illustrates an exemplary set of properties for servlet 304; 

Fig. 17 illustrates an exemplary set of properties for filter engine 306; and 

Fig. 18 illustrates an exemplary set of properties for bank interface 222. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The present disclosure relates to a system and method that permit customers of 
financial institutions to securely obtain online certificate validation and other services. In a 
preferred embodiment, these services are provided within the context of a four-corner trust 
model. A preferred embodiment of this four-corner model is shown in Fig. 1. 
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As shown in Fig. 1, the four-corner model preferably comprises a first institution 
102 and a second institution 104. First institution 102 is referred to as the "issuing 
participant" because it is a participant in the present system and issues smart cards to its 
customers, as described below. Second institution 104 is referred to as the "relying 
participant" because it is a participant in the present system and its customers rely on 
representations made by issuing participant 102 and issuing participant 102's customers, as 
described below. Participants 102, 104 are typically banks or other financial institutions. 

Also shown in Fig. 1 are a first customer 106 and a second customer 108. First 
customer 106 and second customer 108 are preferably customers of issuing participant 102 
and relying participant 104, respectively. First customer 106 is referred to as the 
"subscribing customer" because this customer subscribes to services provided by issuing 
participant 102. First customer 106 is also referred to as the "buyer" because it typically 
fills that role in transactions with second customer 108, as described below. Second 
customer 108 is referred to as the "relying customer" because it relies on representations 
made by both issuing participant 102 and subscribing customer 106. Second customer 108 
is also referred to as the "seller" because it typically fills that role in transactions with first 
customer 106, as described below. It should be recognized, however, that although the 
description below speaks largely in terms of a buyer 106 and a seller 108, first customer 
106 and second customer 108 may instead have different roles in a given transaction. For 
example, first customer 106 may be a borrower repaying a loan to second customer 108. 

Also shown in Fig. 1 is a root entity 110. Root entity 1 10 is typically an 
organization that establishes and enforces a common set of operating rules for facilitating 
electronic commerce and electronic communications. Root entity 110 may be owned 
jointly by a plurality of banks and/or other financial institutions that have agreed to adhere 
to these operating rules. One exemplary embodiment of such a root entity is described in 
copending application serial No. 09/502,450, filed February 11, 2000, entitled System and 
Method for Providing Certification Related and Other Services, which is hereby 
incorporated by reference. 

Fig. 2 is a block diagram depicting components preferably provided at each entity in 
the four corner model. As shown in Fig. 2, participants 102, 104, and root entity 1 10 are 
each preferably provided with a transaction coordinator 202 that serves as a gateway for 
transmitting and receiving all inter-entity messages related to services provided by the 
present system. Each transaction coordinator 202 is preferably provided with an associated 
hardware security module (HSM) 218 for signing and verifying messages. Transaction 
coordinators 202 provide a single interface to issuing participant 102's and relying 
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participant 104's on-line services and implement safeguards necessary to ensure secure 
electronic communications between transaction coordinators 202 and other entities in the 
four-corner model, as described in copending United States patent application serial No. 

, filed on even date herewith, entitled System and Method for Providing 

Certificate Validation and Other Services , which is hereby incorporated by reference. 

Participants 102, 104, and root entity 1 10 are each further preferably provided with 
an Online Certificate Status Protocol (OCSP) responder 204 and associated HSM 206 for 
signing and verifying signatures on messages. 

As further shown in Fig. 2, relying customer 108 is preferably provided with a Web 
server 220 adapted to receive and transmit information via the Internet. Relying customer 
108 is further preferably provided with a bank interface 222 for accessing system services, 
as described in more detail below. Relying customer 108 is preferably further provided 
with a hardware security module 230 for signing and verifying signatures on messages. 

Other components shown in Fig. 2 as well as exemplary services and message flows 
for such services are described in copending United States patent application serial No. 

, filed on even date herewith, entitled System and Method for Providing 

Certificate Validation and Other Services and United States patent application serial No. 

, filed on even date herewith, entitled System and Method for Providing 

Payment Services in Electronic Commerce. 

In a preferred embodiment, each system entity is provided with two digital 
certificates (and corresponding private keys) to facilitate authentication: An identity 
certificate (also referred to, in some cases, as a warranty certificate) and a utility certificate. 



The identity private key is used to produce digital signatures that are required by 
root entity 1 10 as evidence of an entity's contractual commitment to the contents of an 
electronic transaction. A certificate chain is typically required to support operations using 
this key. The status of the identity certificate may be obtained by requesting certificate 
validation. 

The utility private key is used to produce digital signatures that allow additional 
transactional security. Typically, utility certificates are used to support secure socket layer 
sessions, to sign S/MIME messages, and for other utility applications. A certificate chain is 
also needed to support operations using the utility key. The status of the utility certificate, 
however, may not be available to a requester. Throughout this document, the term 
"certificate" refers to an identity certificate unless otherwise stated. 
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In a preferred embodiment, subscribing customer 106's digital certificates and 
associated private keys are provided to it by issuing participant 102. Issuing participant 102 
preferably issues smart cards or other suitable instruments to subscribing customer 106 that 
include at least the private key associated with the subscribing customer's identity 
certificate. If desired, the smart card may also include the subscribing customer's identity 
certificate. Preferred specifications for the smart card, its manufacture, and contents are 
described in copending United States provisional 

patent application serial No. , filed August 14, 2000, entitled Signing 

Interface Requirements, Smart Card Compliance Requirements, Warranty Service 
Functional Requirements, and Additional Disclosure, which is hereby incorporated by 
reference. 

As noted above in the Summary of the Invention, the seller is preferably provided 
with digital signature messaging software for accessing system services. This software is 
preferably integrated with the seller's computer system. Two preferred implementations 
for achieving this integration are described below. 

The first preferred implementation is referred to as passive integration because it 
requires no modification of a seller's existing e-commerce Web application. A preferred 
architecture for implementing passive integration at a seller's Web site is shown in Fig. 3. 

As shown in Fig. 3, seller 108 is preferably provided with several additional digital 
signature messaging software components that supplement the seller's existing e-commerce 
Web server 312 and Web application 310. In particular, seller 108 is preferably provided 
with a filter 302, an SDK Web server 3 12, a servlet 304, a filter engine 306, and a bank 
interface 222. 

Before describing the architecture and operation of each software component in 
detail, a brief overview of overall operation of the digital signature messaging software is 
provided. In general terms, filter 302 intercepts HTTP requests from buyer 106 and 
redirects the requests to SDK Web server 312. SDK Web server 312 parses the request and 
forwards the parsed request to servlet 304. Servlet 304 builds a hash table based on the 
information received from browser 224 and sends the hash table to filter engine 306. Filter 
engine 306 analyzes the hash table to determine if it contains data that requires signing 
and/or a request for a service provided by system 200 (e.g., certificate validation). 

Assume, for example, that data requiring signature is included in an intercepted 
HTTP request. In that event, filter engine 306 formats the data for signing and passes an 
object to servlet 304 indicating that signature is required. Servlet 304 builds a response to 
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browser 224 that invokes a signing interface to cause the buyer's smart card 226 to sign the 
formatted data. 

Preferred embodiments for implementing this signing interface are described in 

copending United States provisional patent application serial No. , filed August 

14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, 
Warranty Service Functional Requirements, and Additional Disclosure, which is hereby 
incorporated by reference. As disclosed therein, in one preferred embodiment this signing 
interface may be implemented using a Java applet downloaded from the customer seller's 
Web server to the buyer's Web browser. 

Using a Java applet to implement the client interface is advantageous for several 
reasons. First, the applet can be automatically downloaded from the server each time it is 
used; therefore, no additional software is required on the signer's machine to support PKI 
integration (except for the drivers necessary for smart card access) and the applet can be 
updated without client distribution requirements. Second, Java is a cross-platform 
technology and therefore use of a Java applet allows the system to support all Java- 
compliant browsers. Third, the OpenCard API provides smart card access from Java. 

In a second preferred embodiment, data signing may be handled by a series of 
browser plug-ins. For example, General Network Solutions (http://www.gns.ca/) provides 
a set of browser plug-ins called FormSign that may be used to sign a form's posted data. In 
this preferred embodiment, one or more plug-ins are installed on the client's machine 
before signing occurs. A plug-in may, for example, be downloaded over the Internet to the 
client's computer the first time the user receives a page referencing it. Plug-ins provide a 
good solution for active integration where the HTML page to be signed can be modified to 
explicitly reference the plug-in. 

The signed data and buyer's certificate are passed back to filter engine 306 which 
then determines whether a system service is required. For example, the seller may wish to 
validate the buyer's certificate. In that event, filter engine 306 transmits a message to bank 
interface 222 which formulates a formal OCSP request and transmits it to transaction 
coordinator 202^, of relying participant 104. An OCSP response is generated as described 

in more detail in copending United States patent application serial No. , 

filed on even date herewith, entitled System and Method for Providing Certificate 
Validation and Other Services, which is hereby incorporated by reference, and returned to 
bank interface 222, which forwards the response to filter engine 306. 

Filter engine 306 then passes an object to servlet 304 indicating the result of the 
certificate status check. Assuming the certificate validates properly, servlet 304 then 
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instructs filter engine 306 to pass the original HTTP request to existing Web application 
310 and retrieve the next page to be transmitted to buyer 106. 

Thus, an important attribute of passive integration is that SDK Web server 312 
receives all incoming connections previously destined for Web server 220. Few changes to 
original Web server 312 are needed, except that it is no longer accessible from the Internet. 
Additionally, existing certificates used for SSL encryption may need to be reconfigured to 
use SDK Web server 312. 

It should be noted that although existing Web server 220 and SDK Web server 312 
are shown as distinct components in Fig. 3, SDK Web server 312 may be implemented as a 
new virtual domain on existing application Web server 220 if it has sufficient processing 
resources. Otherwise a separate Web server may be provided. 

A computer platform for implementing Web server 312 preferably contains a 
minimum of 128 Mb of random access memory and a 10 Mb hard disk. In a preferred 
embodiment, the system may be implemented on the Microsoft Windows NT platform, 
with the following recommended configuration. 



25 



30 



Software 


URL 


Notes 


Windows NT Server 


http://www.microsoft.com 




Windows NT Service 
Pack 4.0 and above 


http://www.microsoft.com 




Windows NT Option 
Pack 4.0 and above 


http://www.microsoft.com 


Includes MS IIS 


Microsoft Visual 
Professional C++ 6.0 


http://www.microsoft.com 


For compiling ISAPI Filter and 
PKCS#11 API 


Visual Cafe 
Professional Edition 
3.0 from Symantec 


http ://www. sun. com 


Includes Java Development Kit 
1 .2. JDK 1 .2 can be down- 
loaded from Sun's Web site 


Jrun Pro 2.2.1 from 
Live Software 


http ://www.livesoftware .com/ 
store/store.jsp 


Servlet run-time engine 


SSL/JfromRSA 
Security Systems 


http ://www.rsa.com/rsa/ 
products/ sslj/index.html 


Crytographic Toolkit (US 
Only) 


J/SSL from Baltimore 
Technologies 


http://www.baltimore.com 


Crytographic Toolkit (Outside 
US Only) 


XETI's JKIX 


http : //www.xeti .com/ 


PKI development toolkit 



35 
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nCipher's HSM 


http://www.ncipher.com/ 


Host Security Module for 






hardware signing 



In a preferred embodiment, Java is used as a language/platform and is compiled to 
an intermediate format called byte codes. These byte codes are then executed by a virtual 
machine. If a Java Virtual Machine (JVM) is available for the target platform, the Java 
code can be executed on that platform. 

Each component of the digital signature messaging software will now be described 
in more detail. Filter 302 provides a high level event-handling mechanism that redirects 
HTTP requests from the seller's application Web server 220 to SDK Web server 312. In a 
preferred embodiment, filter 302 may be implemented using Microsoft IS API (Internet 
Server Application Programming Interface). It should be noted that ISAPI is a Microsoft 
technology that can be used only with Microsoft IIS (Internet Information server). 
However, filters providing similar functionality can also be designed for Netscape's 
Enterprise Server. Filter 302 may comprise libraries that when run intercept specific server 
events and redirect all HTTP requests to SDK Web server 312. 

In a preferred embodiment, filter 302 is adapted to provide enhanced logging 
capabilities by tracking more information than that provided by basic Web server log files. 
In addition, it may employ custom authentication techniques by interposing a unique filter 
with its own user ID and password method on access requests for a particular type of 
resource. 

Sample code for implementing a filter 302 is shown in Fig. 4. In a preferred 
embodiment, distribution of this component may include a compiled DLL (filter.dl 1) 
library and source files (filter.c) used to create the DLL. In addition, the ISAPI extension 
wizard included with Microsoft Visual C++ 6.0 may be used to modify and subsequently 
compile the files. The compiled library must then be added to the Web server's filter list 
with highest priority. 

In a preferred embodiment, servlet 304 transfers all requests redirected by filter 302 
from Web server 312 to filter engine 306, as described in more detail below. Servlets are a 
type of Internet server application (ISA). IS As cause special software applications to run 
when a user requests redirected by filter 302 certain URLs from a Web server. The ISA is 
responsible for accepting incoming connections and passing them to filter engine 306 
according to filter engine 306*s interface. In addition, the ISA is adapted to generate HTTP 
responses based on data received from filter engine 306. 



A number of ISA technologies exist; some are specific to one Web server and others 
are industry-standards supported by most major Web servers. Because the present system 
preferably supports many Web server and platform combinations, a Java implementation is 
preferred for implementing this ISA. Servlet technology is based on Java and is supported 
by several commercially available Web servers through third-party servlet engines. In a 
preferred embodiment, servlet 304 may be implemented using Live Software's Jrun 2.2 
product ( rittp://www.irun.com/) , a servlet engine that provides integration with several 
commercially available Web servers, including Microsoft Internet Information Server 
("IIS"), Netscape Enterprise Server ("NES"), and Apache. 

Performance issues with servlets, however, may drive a decision to implement other 
ISA technologies. For example, in an alternative preferred embodiment, the functionality 
of servlet 304 may instead be provided by an Internet Server Application Programming 
Interface (ISAPI). ISAPI is a C-based ISA developed for Microsoft Internet Information 
Server (US). A port of ISAPI has been done for the Apache Web server as well. The 
corresponding, but different, ISA technology for Netscape Enterprise Server (NES) is 
Netscape Server Application Programming Interface (NSAPI). These two interfaces 
provide close, C-based support for their respective Web servers and therefore provide 
maximum performance. The problem with using these C-based technologies is the number 
of platform and Web server combinations that must be written to cover the same breadth as 
a servlet. Thus, although servlets are typically preferred, ISAPI and NSAPI extensions 
may be written as necessary for select platforms to improve performance. 

In a preferred embodiment, servlet 304 is adapted to maintain the state of filter 
engine 306. When an HTTP request is received from a browser 224, servlet 304 passes a 
hash table to filter engine 306 containing: (1) the headers from the HTTP request; (2) the 
method of the request; (3) the content-type of the request; (4) the client IP address; (5) the 
actual data in the request; and (6) a unique session ID. 

Filter engine 306 processes the hash table and returns a return object to servlet 304 
with an integer value indicating one of four conditions: (1) a signature is required on data in 
the HTTP request; (2) a response has been received from relying participant 104 
concerning a service request that had been made; (3) the HTTP request has been passed 
through to Web application 310; or (4) an error occurred. Servlet 304 finishes processing 
the received HTTP request based on this integer value, as described below in the 
description of servlet 304 process flow. 

In a preferred embodiment, servlet 304 may be constructed as a public class object 
that extends javax.servlet.http.HttpServlet. Illustrative methods for this object are shown 
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and described in the table below. Methods inherited from the parent classes 
javax.servlet.http.HttpServlet, javax.servlet.GenericServlet, and javalang are not shown in 
the table. 



5 



10 



15 



Servlet Method Summary 


ReturnObiect 


callFilterEnainefi ava.util .Hashtable theHashtable) 




Calls the filter engine to determine if the request needs to 
be signed. 


void 


doGet(javax.servlet.http.HttpServletRequestreq, 
javax.servlet.http.HttpServletResponseres) 
Handles all GET requests coming from a Web browser. 
JRUN automatically creates a thread of this method for 
every request, thus this method must be thread-safe. 


void 


doPostfiavax.servlet.http.HttpServletRequestreq, 
javax.servlet.http.HttpServletResponse res) 
Handles all POST requests coming from a Web browser. 
JRUN automatically creates a thread of this method for 
every request, thus the method must be thread safe. 


j ava.util .Hashtable 


^etRequestHeadersfiavax.servlet.http.HttpServletRequest 
req) 

Places all HTTP headers coming from the browser in a 
hashtable. 


void 


handleReauestriavax.servlet.ServletOutputStream out, 

j avax. servlet.http .HttpSession currentSession, 

j avax. servlet.http.HttpServletRequest req, 

j avax. servlet.http .HttpServletResponse res, 

j ava.util .Hashtable theHash, byte[] binaryData, 

java.lang.String theQuery, java.lang. String 

theContentType) 

This method handles every HTTP request coming from a 
signing interface. 


void 


initCjavax.servlet.ServletConfig config) 
Initializes the servlet and loads servlet properties. 



35 
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printErrorResponsefiava.util.Hashtable headers, 
javax.servlet.ServletOutputStream out, java.lang.String 
theMessage) 

Builds error HTML response. 


5 




printPluginPaaefi avax. servlet.ServletOutputStream out, 
java.lang.String theQuery) 

Builds the HTML page that will display the data signing 
plug-in. 


10 


bvten 


readMessagefiavax.servlet.http.HttpServletRequest req) 
Reads the posted data regardless of its MIME-type, 
whether binary data such as MS-WORD, HTML, and text 
documents. 


15 


Java util .Vector 


readRequestDatad avax . servlet.http.HttpS ervletReq uest 
req, javalang. String theMethod) 
Recreates the x-www-form-url-encoded query string 
posted by a browser. 


20 


j avax. servlet .http . 
HttpServletResponse 


setServIetHeadersfiavax.servlet.http.HttpServletResponse 
res, java.util.Hashtable theHeaders) 

Copies headers from the Web application response back to 
the browser response. 



In a preferred embodiment, ReturnObiect may take the following form: 

ReturnObject{ 
Int={ 

25 Constants. WEBAPP | 

CertStatus.GOOD | 
CertStatus.REVOKED | 
CertStatus.UNKNOWN | 
Constants. SUCCESS | 
Constants.EXCEPTION | 
} 

30 

String = {Business Determined} 

Hashtable = { 

{Constants.PAGE} 

{ Constants.HEADERS } 

{Constants.SERVICE} 

{Constants.MODE} 

} 

35 } 
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An example of servlet 304 process flow is now described in connection with Fig. 5. 
As shown in Fig. 5, in step 502, servlet properties are loaded from a properties file. In step 
504, servlet 304 reads data from a received HTTP request. In step 506, servlet 304 creates 
a hash table (comprising name and value pairs) with parameters for filter engine 306 

- including HTTP headers, client IP address, HTTP method (GET and SET), content type, 
and the actual data in the request. In step 508, servlet 304 determines if data in the HTTP 
request has been signed. If it has not been signed, in step 510, servlet 304 calls filter engine 
306 with the hash table. Otherwise, in step 512, servlet 304 URL decodes the PKCS#7 
message received from browser 224, inserts it into the hash table, and calls filter engine 306 

jq with the hash table. 

In step 514, servlet 304 receives a return object with an integer value indicating one 
of the four conditions described above. Based on this value servlet 304 finishes processing 
the original request In particular, if the return value from filter engine 306 indicates that 
Web application 310 has been called, then in step 516, servlet 304 causes the next Web 

j 5 page to be transmitted to Web browser 224. If the return value from filter engine 306 
indicates that the page needs to be signed, then, in step 518, servlet 304 stores the state of 
filter engine 306 in a cookie and causes the page with the signing interface plug-in to be 
transmitted to Web browser 224. If the return value from filter engine 306 indicates that 
the client certificate is good then, in step 520, servlet 304 changes the state and sends a 

20 request to filter engine 306 to retrieve the next page to be displayed to buyer 106. For all 
other values or exceptions, servlet 304 displays an error page to the client, as shown in step 
522. 

Filter engine 306 receives HTTP requests from servlet 304 and applies filtering 
rules to distinguish pages that need to be signed or that require a system service from pages 

25 that should be passed to existing Web application 310. The rules may be loaded when filter 
engine 306 is first instantiated. The contents of the rules files may be a function of the 
seller's existing Web application 310 and business process. 

HTTP requests that include data to be signed may be recognized by filter engine 
306 in a variety of ways. In one preferred embodiment, filter 306 may be programmed to 

3 q recognize each HTTP request that includes data to be signed on the basis of data included 
in the posted HTTP request data. Rules may be defined that identify data requiring 
signature. This variation requires application knowledge and advanced knowledge of the 
Web application's architecture. An understanding of the data being posted and how each 
posting differs in the application must be gained. 

35 
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Alternatively, HTTP requests transmitted by Web browser 224 may be modified to 
include a special tag that indicates whether the request needs to be signed. For example, a 
hidden field identifying the request as requiring signature may be added to a form or an 
additional HTTP header line may be added to the request. Alternatively, HTTP requests 

^ requiring signature may be recognized by changing the suffix for the ISA file to handle the 
request (e.g., submit.dll to submit.sdll) for forms posting. If the requests are modified to 
include a special tag, the rules defined for filter engine 306 may be simplified and 
generalized for all posts requiring signatures. This alternative embodiment requires code 
modification to some degree, but should improve performance. 

2 o Fig. 6 illustrates an exemplary format of a rules file for filter engine 306 in a 

preferred embodiment. In the example shown in Fig. 6, the rules have been built to analyze 
a Web based collaboration tool known as AltaVista Forums. There are four rules in the 
example. A rule definition consists of: a mode (synchronous/asynchronous), a service (e.g., 
certificate validation), and a sequence of parameter names and values (location, name, and 

2 5 value; cookie, AltaVistaForum_AuthToken, and dsmith in the example). The first two 
parameters are the mode and service followed by one to n transaction specific parameters. 
Each parameter is separated with a semicolon and within parameters by a comma. New 
services may be added by installing a new plug-in module and modifying the rules file to 
utilize the new capability. 

20 In a preferred embodiment, filter engine 306 provides an abstracted front-end 

interface via Java Remote Method Invocation (RMI). 

In a preferred embodiment, filter engine 306 may be implemented as a public class 
object that extends java.lang. Object. This class implements one of the public services 
provided by filter engine 306's RMI server. Illustrative methods for this object are 

25 shown and described in the table below. Methods inherited from the parent class 
java.lang.object are not shown in the table. 



30 



Filter Engine Method Summary 


ReturnObiect 


callWeb App(j ava.util.Hashtable theHasli> 

Creates an HTTP or HTTPS connection to a Web Application according 
to the parameters in a Hashtable. 


long 


getSessionlDO 

A thread safe method for generating signed transaction IDs. 



35 
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5 



10 



RetumObiect 


newRequestHandlerfiava.util.Hashtable theHash) 

Method called when the sate of the FilterEngine is FE_NEW_REQUEST. 


RetumObiect 


oldRequestHandlerfiava.util.Hashtable theHash) 
Method called when the state of the FilterEngine is 
FEREQUESTCHECKED . 


RetumObiect 


servicefjava.util.Hashtable theHash") 
Implementation of one of IRmiServer public services. 


RetumObiect 


signedRequestHandlerfj ava.util.Hashtable theHash) 

Method called when the state of the FilterEngine is FE_SIGNED_DATA. 



When the RMI server is started, it creates an instance of the filter engine class which 
loads and validates the rules file as part of its constructor. Fig. 7 illustrates sample code 
that may be used in a preferred embodiment to invoke the filter engine RMI server. The 
rules class may be a public class object that extends java.lang.Object used by filter engine 
306 to process the rules. A preferred embodiment of the construction of rules process 
methods is shown in the table below. 



25 



Rules Process Method Summary 


javalang.String 


getModef) 

Returns the mode associated with a particular rule. 


java.lang. String 


getServicef) 

Returns the service associated with a particular rule. 


static 

java.util. Vector 


readRulesfi ava. lane. String theFileName) 

Reads all rules from the RulesFile and stores them in a vector. 


boolean 


rulesMatchO 

Examines an HTTP request and determines if it needs to be 
signed. 


static void 


validateRulesfjava.util. Vector rules') 

Validates rules format, content, and naming of rule elements. 



Fig. 8 illustrates a preferred embodiment of the steps invoked when filter engine 
306's RMI server is started. As shown in Fig. 8, in step 802, filter engine 306 loads filter 
25 engine properties from a properties file. In step 804, filter engine 306 opens log files. In 
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step 806, filter engine 306 loads utility certificates. In step 808, filter engine 306 loads the 
RMI server policy file. In step 810, filter engine 306 loads the rules file into memory. In 
step 812, filter engine 306 validates the rules to verify correct formatting. Filter engine 306 
is then ready to receive requests. 

5 Fig. 9 illustrates a preferred embodiment of the steps invoked when servlet 304 

sends a request to filter engine 306. As shown in Fig. 9, in step 902, filter engine 306 
receives an HTTP request and filter engine 306's state from servlet 304. If the state is 
FE_NEW_REQUEST, filter engine 306 invokes the state handler newRequestHandler 
which compares the request against signing rules, determines whether the request has to be 

jq signed, and builds a return object to be sent back to servlet 304 (step 904). If the state is 
FE_SIGNED_DATA, filter engine 306 executes the state handler signedRequestHandler, 
calling bank interface 222 to check the status of the certificate. Bank interface 222 returns 
the status of the certificate and filter engine 306 passes this status back in a return object to 
servlet 304 (step 906). If the state is FEREQUESTCHECKED, indicating the final stage 
of a signed transaction, filter engine 306 executes the state handler oldRequestHandler, thus 
calling Web application 310. The original page is retrieved from Web application 310 and 
its content is returned to servlet 304 in a return object (step 908). 

A preferred embodiment for implementing bank interface 222 is shown in Fig. 10. 
As shown in Fig. 10, bank interface 222 is preferably designed with a plug-in based 

20 architecture that allows new service modules (e.g., certificate status check module 1010, 
warranty 1020, etc.) to be added as they are created. 

Relying customer 108 initiates a service request by accessing one of these modules, 
which ensures proper message formatting and protocol handling. For example, certificate 
status check module 1010 creates a proper OCSP request and submits it to relying 

25 participant 104. 

In a preferred embodiment, bank interface 222 supports an abstract front-end 
interface to allow communication via several different middleware technologies used to 
access it from other code modules. A number of technologies may be used to access bank 
interface 222 including Common Object Request Broker Architecture ("CORBA"), 

30 Component Object Model ("COM"), Remote Method Invocation ("RMI"), and TCP/IP 
Sockets. In a preferred embodiment, an RMI binding implementation may be used to 
expand the abstract interface to include CORBA and COM versions. 

Fig. 1 1 illustrates the steps invoked when the RMI server of bank interface 222 is 
started in a preferred embodiment. As shown in Fig. 1 1 , in step 1 102, bank interface 222 

35 loads bank interface properties from a bank interface file. In step 1 104, bank interface 222 
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loads log files. In step 1 106, bank interface 222 loads utility certificates. In step 1 108, 
bank interface 222 loads the RMI server policy file. In step 1110, bank interface 222 loads 
cryptographic modules, either software or hardware as specified in the properties file. At 
this point, bank interface 222 is ready to receive service requests from filter engine 306 and 
to call the bank interface service manager with a service request that contains the name of 
the service, mode of the service, and a message. 

Fig 12 illustrates the steps invoked when filter engine 306 sends a request to bank 
interface 222 in a preferred embodiment. As shown in Fig. 12, in step 1202, bank interface 
222 retrieves relying customer 108's and root entity 1 10's certificates from memory. In step 
1204, bank interface 222 retrieves subscribing customer 106's and issuing participant 102's 
certificates from a CMS (Cryptographic Message Syntax) also referred to as PKCS#7 
received from buyer 106. In step 1206, bank interface 222 verifies the signature on the 
CMS message and checks the integrity of the signed data. In step 1208, bank interface 222 
verifies the signature on subscribing customer 106's certificate using issuing participant 
102's certificate. In step 1210, bank interface 222 verifies the signature on issuing 
participant 102's certificate using root entity 1 10's certificate. In step 1212, bank interface 
222 checks the validity period on those two certificates against the current date. In a 
preferred embodiment, bank interface 222 does basic path validation as specified in RFC 
2459 Section 6.1 on the certificate chain extracted from the PKCS#7 message. 

In step 1214, bank interface 222 retrieves the URL for OCSP responder 204^ from 
relying customer 108's certificate. In step 1216, bank interface 222 creates an OCSP 
request for subscribing customer 106's certificate signed by relying customer 108. All 
OCSP requests preferably contain a Service Locator Extension used to locate the relying 
participant which is set by an Authority Information Access (AIA) extension defined in the 
seller's certificate. Alternatively, bank interface 222 may employ a different mechanism to 
configure the location of relying participant 104 which may override the location 
information in the AIA extension. In a preferred embodiment, bank interface 222 supports 
both raw OCSP and OCSP wrapped in XML. Preferred aspects of both a raw OCSP 
embodiment and an OCSP wrapped in XML embodiment are described below. 

In step 1218, bank interface 222 logs the OCSP request in a transaction log. In step 
1220, bank interface 222 creates an HTTP(S) connection to OCSP responder 204^ and 
transmits the OCSP request to it. In a preferred embodiment, bank interface 222 may be 
adapted to transmit all OCSP requests to relying participant 104, even when bank interface 
222 can tell that relying participant 104 is not the participant that issued the certificate that 
is the subject of the request. In step 1222, bank interface 222 receives an OCSP response 
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from OCSP responder 204^ and verifies the signature on the response using OCSP 
Responder 204 RP 's certificate. In step 1224, bank interface 222 extracts the status of 
subscribing customer 106's certificate from the response. Steps 1216 to 1224 are repeated 
for issuing participant 102's certificate and relying participant 104's OCSP Responder' s 
certificate as shown in step 1226. In step 1228, bank interface 222 logs the OCSP response 
for each of these requests to the transaction log. 

If the status of all the responses is "good" then, in step 1230, bank interface 222 
returns a message to that effect to filter engine 306. Otherwise, bank interface 222 returns 
the status of the checked certificate to filter engine 306. In step 1232, bank interface 222 
logs all signed requests to an event log and all errors to an error log. All exceptions are 
returned to the client as a part of the return object. 

A preferred embodiment of the methods that may be incorporated in a certificate 
status check module of bank interface 222 are shown in the table below. These methods are 
used to perform the basic steps described above for certificate status checking. Bank 
interface certificate status checking method is preferably a public class object that extends 
java.lang.Object. The methods inherited from the parent class java.lang.Object are not 
shown in the table. 



20 



25 



30 



Certificate Status Check Method Summary 


EOCSPReauest 


createOCSPRequestCcom.identrus.bankinterface 
.Certificate cert, 

com.identrus.bankinterface.Certificate issuerCert, 

com.identrus.bankinterface.Certificate 

RequestorCert, 

com.identrus.bankinterface.CertID certld) 
Creates an OCSPRequest with the corresponding 
extensions necessary for forwarding/proxying. 


com.identrus.bankinterface.Cer 
tID 


getCertificatelDf com.identrus.bankinterface.Cer 
tificate cert) 

Builds a CertID object that identifies a certificate. 



35 
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5 


void 


getCertStatusf com.identrus .bankinterface.OC SP 
Response resp, 

com.identrus.bankinterface.CertID certld, int 
certType) 

Retrieves the status of a certificate, by ID, from 
an OCSP response and checks its status. 


10 


void 


getCertsVerifvMessasefcom.identrus.bankinterf 
ace.SignedData sd, java.util.Hastable data) 
Get the SC, CA Certificates from the CMS 
Message, and verify the signature on the CMS 
Message. 




java.lang.String 


getURLfcom.identrus.bankinterface.Certificate 
c) 

Get the URL from the AuthoritylnfoAccess 
certificate extension. 


15 






boolean 


isResponseSuccessfuKcom.identrus.bankinterfac 

e.OCSPResponse resp) 

Check the OCSP response status. 


20 


void 


logAndBuildReturnObjectfint certStatus, 

java.lang.String strMessage) 

Log the OCSP response results, and build the 

ReturnObject. 


25 


void 


processOCSPfcom.identrus.bankinterface.Certifi 
cate cert, com.identrus.bankinterface.Certificate 
issuer, com.identrus.bankinterface.Certificate 
requestor, int certType) 

Checks the status of a certificate issued by the 
issuer and is being checked by the requestor. 


30 


com. identrus .bankinterface . OC 
SPResponse 


sendAndReceiveMessage(EOCSPRequestreq) 
Sends an OCSPRequest and retrieves the 
OC SPResponse received from the Responder. 
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ReturnObiect 


serviceRequestCiava.util.Hashtable data) 

The main logic for the Certificate Status Check 

Service. 


com.identrus.bankinterface.Cer 
tificate 


verifVResponseSignature(com.identms.bankinte 

rface.OCSPResponse resp) 

Retrieves responder certificates from the response 

and verifies the Signature of the OCSP response. 



10 An example of system operation using the passive integration implementation 

described above is shown in Fig. 13. As shown in Fig. 13, in step 1301, a buyer 106 clicks 
the 'Submit' button on an HTML form displayed to buyer 106 by Web browser 224. In step 
1302, Web browser 224 posts form data to seller 108's Web site. In step 1303, filter 302 
redirects the received HTTP request to servlet 304. In step 1304, servlet 304 passes the 

1 5 HTTP request to filter engine 306. In step 1 305, filter engine 306 determines if the HTTP 
request requires signature by buyer 106 and, if so, creates a Return-to-Browser URL (as a 
GET with parameters for data) representing the data of the original POST or GET form 
posting and returns it along with instructions to get the data signed to servlet 304. In step 
1306, servlet 304 builds a response with either an applet tag pointing to the signing 

20 interface applet or a call to a browser plug-in, the arguments Return-to-Browser URL, and 
the data to sign. 

In step 1307, SDK Web server 312 returns servlet 304's response to Web browser 
224. In step 1308, Web browser 224 displays the HTML page and, if necessary, requests 
the appropriate signing interface applet or plug-in. In step 1309, Web browser 224 displays 
25 the client interface applet or activates the plug-in. Arguments may include the data to be 
signed and possibly a URL. 

In step 1310, buyer 106 clicks a button to approve signing of the form data. In step 
1 3 1 1 , the client interface (applet or plug-in) calls a smart card API to request that smart 
card 226 sign an SHA-1 hash of the form data. In step 1312, buyer 106 enters its PIN when 
30 the driver asks for it. 

In step 1313, the smart card API returns the signed form data to the signing 
interface. In step 1314, the signing interface makes an HTTP connection to SDK Web 
server 312 and submits the signed form data. In step 1315, SDK Web server 312 passes the 
request to servlet 304. 
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In step 1316, servlet 304 passes the request to filter engine 306. In step 1317, filter 
engine 306 calls bank interface 222 with the signed data. In step 1318, bank interface 222 
creates an OCSP request and calls the open card API to request that seller 108's HSM sign 
an SHA-1 hash of the request. 

In step 1319, open card API calls seller 108's HSM OS Driver. In step 1320, HSM 
OS Driver calls seller 108's HSM to sign the request. In step 1321, the HSM OS Driver 
returns the signed request to open card API. 

In step 1322, open card API returns the signed request to bank interface 222. In 
step 2028, bank interface 222 transmits the request to relying participant 104. In step 2029, 
relying participant 104 forwards the request to issuing participant 102. 

In step 1330, issuing participant 102 returns a signed response to relying participant 
104. In step 1331, relying participant 104 requests validation of issuing participant 102's 
certificate from root entity 110. In step 1 332, root entity 1 10 returns a signed OCSP 
response to relying participant 104. 

In step 1333, relying participant 104 returns a signed OCSP response to bank 
interface 222. In step 1334, bank interface 222 validates the signed data and records the 
transaction in the log. In step 1335, bank interface 222 validates the signed data and stores 
the signed data and the signed response from relying participant 104 in SDK Web server 
312's database. 

In step 1336, bank interface 222 returns an OK or failure result to filter engine 306. 
In step 1337, filter engine 306 returns failure result to servlet 304 or passes initial request to 
Web application server 220. In step 1338, if the request for system service resulted in a 
failure (e.g., if the result of a certificate status check was that the certificate is not valid), 
servlet 304 builds a response indicating that a failure occurred. In step 1339, SDK Web 
Server 3 12 returns servlet 304's failure response to browser 224. 

As noted, the second preferred implementation for integrating digital signature 
messaging software with a seller's existing Web application is referred to as active 
integration because it requires modification of the seller's existing Web application. A 
preferred architecture for implementing active integration at a seller's Web site is shown in 
Fig. 14. As shown in Fig. 14, the seller's Web site is preferably provided with a bank 
interface 222 in addition to its existing Web server 220 and Web application 310. The 
functionality of the other digital signature messaging software components described above 
is preferably incorporated directly into Web application 310. 

If the seller's Web application 3 1 0 exposes an Application Programming Interface 
(API) for enhancements, it may be used to integrate the application with the disclosed pubic 
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key infrastructure. If Web application 3 10 is implemented using a tool with a set of APIs 
and well-documented techniques extending the application, developers with less knowledge 
of Web application 3 10 and its technologies may be able to implement the active 
integration solution. If no API exists, the actual source code of Web application 310 or the 

5 tool used to build it may be modified. In either case, the integration code is preferably 
adapted to call bank interface 222, effectively bypassing the need for filter engine 306. 

Active integration requires advanced knowledge of the technologies used to 
implement Web application 310. One important attribute of active integration in 
comparison to passive integration is that all incoming requests are processed in their 

10 traditional manner, as opposed to being filtered. This results in a positive performance gain 
compared to passive integration. 

An example of system operation using the active integration implementation 
described above is shown in Fig. 15. As shown in Fig. 15, in step 1501, 
buyer 106 requests a form that will require signing when submitted. In step 1502, Web 

15 browser 224 submits an HTTP request to seller 108's Web site. In step 1503, Web server 
220 forwards the HTTP request to Web application 310. 

In step 1504, Web application 310 returns an HTML page that references the client 
signing interface. In step 1505, Web server 220 returns the HTML page to Web browser 
224. In step 1506, Web browser 224 requests the client signing interface from Web server 

20 220 - 

In step 1507, Web server 220 retrieves the client signing interface. In step 1508, 
Web server 220 returns the client signing interface to Web browser 224. In step 1509, 
buyer 106 clicks the submit and sign button on the displayed Web page. 

In step 1510, Web browser 224 calls the client signing interface. In step 1 5 1 1 , the 
2 5 client signing interface calls Windows PC/SC to have the buyer's smart card 226 sign the 
data. In step 1512, buyer 106 enters its PIN. 

In step 1513, Windows PC/SC calls buyer 106's smart card 226 to sign the data. In 
step 1514, Windows PC/SC returns the signed data to the signing interface. In step 1515, 
the signing interface returns the signed data to Web browser 224. 
30 In step 1516, Web browser 224 posts the signed data to Web server 220. In a 

preferred embodiment, the posted data is a PKCS#7 message. In step 1517, Web server 
220 passes the signed posting to Web application 310. In step 1518, integration code added 
to Web application 310 calls bank interface 222 to verify the signature on the form. 

In step 1519, bank interface 222, generates an OCSP request and calls HSM OS 
^ 5 Driver to sign it. As noted above, bank interface 222 may retrieve subscribing customer 
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106's and issuing participant 102's certificates from a CMS (Cryptographic Message 
Syntax) also referred to as PKCS#7 received from buyer 106 and preferably verifies the 
signatures on the CMS message and buyer's certificate, and checks the integrity of the 
signed data. 

5 In step 1 520, HSM OS Driver calls HSM 230 to sign the OCSP request. In step 

1521, HSM OS Driver returns the signed request to bank interface 222. In step 1522, bank 
interface 222 transmits the request to relying participant 104. In step 1523, relying 
participant 104 forwards the request to issuing participant 102. In step 1524, issuing 
participant 102 returns a signed OCSP response to relying participant 104. In step 1525, 

1Q relying participant 104 calls root entity 1 10 to validate the certificates of issuing participant 
102. In step 1526, root entity 110 returns a signed response to relying participant 104. 

In step 1527, relying participant 104 returns the signed response to interface 222. 
In step 1528, bank interface 222 stores the signed data and the signed response from relying 
participant 104 in a signed documents repository. In step 1529, bank interface 222 writes a 

j 5 transaction log message. In step 1 530, bank interface 222 returns the result of the request 
to Web application 310. In step 1531, Web application 310 interprets the form post and 
returns the next page (or an error) to Web server 220. In step 1532, Web server 220 returns 
the page to Web browser 224. 

In a preferred embodiment, the system supports flat (text) files and Microsoft 

2Q Access. Logging with MS-Access may be achieved using ODBC drivers, commonly 
distributed for all Windows platforms. Also provided in a preferred embodiment is a 
transaction monitoring tool. The tool helps relying customer 108 query the transaction log. 
The following information is preferably stored as a log: subscribing customer 106's IP 
address, subscribing customer 106's name extracted from the certificate, the date and time 

2 5 of the transaction, the name of the service, the mode of the service (synchronous or 
asynchronous), and the message logged. 

As indicated above, properties are used to configure various components of the 
present system by supplying user defined parameter values contained in a file. Fig. 16 
illustrates an exemplary set of properties for servlet 304. Fig. 17 illustrates an exemplary 

3 Q set of properties for filter engine 306. Fig. 18 illustrates an exemplary set of properties for 
bank interface 222. 

As noted above, in a preferred embodiment, bank interface 222 supports both raw 
OCSP and OCSP wrapped in XML. In a preferred embodiment, bank interface 222 is 
adapted to provide the following features in supporting raw OCSP: 

35 
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1. Establish an SSL connection for all OCSP requests and responses. Client 
authentication is preferably not provided for this SSL session. 

2. Verify the revocation status of each certificate in the chain except that of root 
entity 110. 

3. Not verify the revocation status of root entity 1 10's certificate. 

4. Cause all OCSP requests to be signed with relying customer 108's private signing 

key. 

5. Authenticate all OCSP responses. 

6. Include a nonce in the OCSP request in cases where a fresh response (rather than 
a cached response) is being transmitted. The OCSP response preferably includes the nonce 
submitted in the initial request. 

7. If desired, the "Freshness Proof of relying participant 104's certificate may be 
ignored. In that case, a new OCSP request is preferably made for the revocation status of 
relying participant 104's signing certificate. 

In a preferred embodiment, bank interface 222 is adapted to provide the following 
features in supporting OCSP wrapped in XML: 

1 . Conform XML requests to a messaging set defined by root entity 110. An 
exemplary messaging set is described in copending United States provisional patent 

application serial No. , filed on even date herewith, entitled Transaction 

Coordinator Certificate Status Check (CSC) Protocol Definition, Transaction Coordinator 
Messaging Protocol Definition, and Transaction Coordinator Requirements, which is 
hereby incorporated by reference. 

2. Generate and use a unique transaction ID. 

3. Cause the XML request to be signed by relying customer 108's private key. If 
desired, the embedded OCSP request may also be signed by the Relying Customer's signing 
key. 

4. A nonce may be included in the embedded OCSP request to indicate that a fresh 
response is required rather than a cached response. 

5. If desired, the "Freshness Proof of relying participant 104's certificate may be 
ignored. In that case, revocation information regarding relying participant 104's signing 
certificate is preferably verified in a separate request. 

In a preferred embodiment, the digital signature messaging software described 
above is adapted to process a signed PKCS#7 request from subscribing customer 106 and 
post a Certificate Status Check request to relying participant 108 in one second or less. 
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Certificate status check responses from relying participant 104 are preferably processed in 
one second or less. 

In a preferred embodiment, the digital signature messaging software described 
above is adapted to reliably handle 350 concurrent requests without any performance 
degradation in a single minute at peak load. In a preferred embodiment, the digital 
signature messaging software described above is available 90 % of the time during 
interoperability testing and 95% of the time during pre-production testing. During 
production, availability preferably meets requirements specified by root entity 1 10. 

In an alternative preferred embodiment, rather than supporting both raw OCSP and 
OCSP wrapped in XML, the system may employ a pure XML implementation. Standards 
based protocols for certification validation may also be considered rather than devising a 
new proprietary protocol. One such protocol is the "Simple Certificate Validation Protocol 
(SCVP)'* which is in an Internet-draft form at the current time. This protocol would enable 
a relying customer 108 to offload path validation responsibilities to a remote path 
processing server (RPPS). More information about this protocol may be found at the IETF 
web site http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-02.txt. 

While the invention has been described in conjunction with specific embodiments, it 
is evident that numerous alternatives, modification, and variations will be apparent to those 
skilled in the art in light of the foregoing description. 
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CLAIMS 



1 . A system for integrating a seller's Web site with a public key infrastructure, the 
5 Web site comprising a Web server and a Web application, the public key infrastructure 

comprising a buyer computer comprising a Web browser adapted to invoke a signing 
interface to digitally sign electronic messages, the public key infrastructure further 
comprising a seller's bank computer system adapted to receive service requests from the 
seller and respond to those requests with digitally signed service responses; the system 
jq comprising: 

a filter adapted to redirect HTTP requests received from the Web browser; 
an Internet server application adapted to receive a redirected HTTP request from the 
filter and process the redirected HTTP request; 

a filter engine adapted to receive the processed HTTP request and identify an HTTP 
j 5 request that contains data requiring signature by the buyer. 

2. The system of claim 1 , wherein the filter engine is further adapted to identify an 
HTTP request that requires accessing a service offered by the seller's bank and to formulate 
a request for the service, and wherein the system further comprises: 

2Q a bank interface adapted to receive the request from the filter engine, reformat the 

request, and transmit the request to the seller's bank. 

3. The system of claim 2, wherein the bank interface is further adapted to receive a 
service response to the request from the seller's bank and forward the response to the filter 

25 engine. 

4. The system of claim 2, wherein the service is certificate validation. 

5. The system of claim 1, further comprising a second Web server adapted to parse 
2Q requests redirected by the filter. 

6. The system of claim 1 , wherein services provided by the seller' s bank are provided 
within the context of a four-corner model. 

35 
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7. The system of claim 6, wherein the four-corner model comprises the buyer, the 
seller, the seller's bank, and a buyer's bank. 

8. The system of claim 1 , wherein the filter is implemented using IS API. 

5 

9. The system of claim 1 , wherein the Internet service application is adapted to 
generate HTTP responses based on data received from the filter engine. 

1 0. The system of claim 1 , wherein the Internet server application is adapted to pass a 
I q hash table to the filter engine. 

1 1 . The system of claim 1 0, wherein the hash table comprises the headers from the 
redirected HTTP request. 

j 5 12. The system of claim 10, wherein the hash table comprises the method of the 
redirected HTTP request. 

1 3 . The system of claim 1 0, wherein the hash table comprises the content-type of the 
redirected HTTP request. 

20 

14. The system of claim 1 0, wherein the hash table comprises the buyer computer' s IP 
address. 

1 5 . The system of claim 1 0, wherein the hash table comprises the actual data in the 
25 redirected HTTP request. 

1 6. The system of claim 1 0, wherein the hash table comprises a unique session ID . 

1 7. The system of claim 1 , wherein the Internet service application is a servlet. 

30 

18. The system of claim 20, wherein the servlet is constructed as a public class object 
that extends javax.servlet.http.HttpServlet. 

1 9. The system of claim 21 , wherein the public class object comprises a 

35 callFilterEngine method, a doGet method, a doPost method, a getRequestHeaders method, a 
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handleRequest method, and init method, a printErrorResponse method, a printPluginPage 
method, a readMessage method, a readRequestData method, and a setServletHeaders 
method. 

5 20. The system of claim 1 , wherein the filter engine is adapted to return an object to the 
servlet. 

21 . The system of claim 20, wherein the object comprises an integer value indicating 
one of four conditions: that a signature is required on data in the HTTP request, that a 

1 0 response has been received from the seller's bank concerning a service request, that the 
HTTP request has been passed through to the Web application, or that an error occurred. 

22. The system of claim 1 , wherein if the integer value indicates that a signature is 
required on data in the HTTP request then the Internet server application stores a state of 

15 the filter engine in a cookie and causes a Web page containing the cookie and an instruction 
to sign the data to be transmitted to the Web browser. 

23 . The system of claim 1 , wherein the filter engine determines whether an HTTP 
request contains data requiring signature by applying filtering rules. 

20 

24. The system of claim 1 , wherein the filter engine is programmed to recognize each 
HTTP request that includes data requiring signature. 

25 . The system of claim 1 , wherein the filter engine is programmed to recognize HTTP 
25 requests transmitted by the Web browser that have been modified to include a special tag 

that indicates whether the request includes data that requires signature. 

26. The system of claim 1 , wherein the filter engine is implemented as a public class 
object that extends java.lang.object. 

30 

27. The system of claim 26, wherein the public class object comprises the following 
methods: a callWebApp method, a getSessionID method, a newRequestHandler method, an 
oldRequestHandler method, a service method, and a signedRequestHandler method. 

35 
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28. The system of claim 1 , wherein the filter engine provides an abstracted front end 
interface via java remote method invocation. 

29. The system of claim 1 , wherein the filter engine employs a rules class. 

5 

30. The system of claim 1 , wherein the rules class comprises the following methods: a 
getMode method, a getService method, a readRules method, a rulesMatch method, and a 
validateRules method. 

! 0 31. The system of claim 1 , wherein the bank interface is designed with a plug-in based 
architecture. 

32. The system of claim 1, wherein the bank interface supports an abstract front-end 
interface to allow communication via a plurality of middleware technologies. 

15 

33. The system of claim 1 , wherein the bank interface is adapted to create and transmit 
OCSP requests. 

34. The system of claim 1, wherein the bank interface comprises a certificate status 
20 check module. 

35. The system of claim 1 , wherein the bank interface comprises a public class object 
that extends java.lang. object. 

25 36. The system of claim 1, wherein the public class object comprises a 

createOCSPRequest method, a getCertificatelD method, a getCertStatus method, a 
getCertsVerifyMessage method, a getURL method , an isResponseSuccessful method, a 
logAndBuildReturnObject method, a processOCSP method, a sendAndReceiveMessage 
method, a serviceRequest method, and a verify ResponseSignature method. 

30 

37. A system for integrating a seller's Web site with a public key infrastructure, 
comprising: 

a Web server; 

a Web application connected to the Web server, the Web application adapted to 
35 identify HTTP requests that include data requiring signature and to create a Web page for 
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transmission to a browser that will cause the browser to invoke a signing interface to sign 
the data; 

the Web application further adapted to identify HTTP requests that require a 
service provided by an entity other than the seller; and 

a bank interface adapted to receive a request for service from the Web application, 
format and transmit the request, receive a response to the request, and forward the response 
to the Web application. 
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Abstract 



A system and method are disclosed for facilitating access to a plurality of 
certificate-related and other services including certificate validation. A seller is provided 
with digital signature messaging software for accessing these services. Two preferred 
implementations are disclosed for integrating a seller's existing Web server and 
applications with this software. The first preferred implementation is referred to as 
"passive integration" because it requires little or no modification to a seller's existing e- 
commerce Web application. In this first implementation, the seller's Web site is preferably 
provided with five additional components: a Web filter for redirecting HTTP requests, a 
second Web server for parsing the redirected HTTP requests, a servlet that runs 
applications based on the requested URL, a filter engine that identifies pages from a buyer 
that require the buyer's signature as well as pages that require access to system services, 
and a bank interface that receives requests to access system services from the filter engine, 
and processes those requests. The second preferred implementation is referred to as "active 
integration" because it requires the seller to rewrite code of its Web applications to provide 
the functionality necessary to access system services. In active integration, the seller's Web 
site is preferably provided with the bank interface described above but the functionality 
provided by the other digital signature messaging software components is instead provided 
by modifying directly the seller's Web application. 
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Figure 3 DSMS Passive Integration 3oZ 



// Redirect anything specific to an application to go through the 
// DSMS 

DWORD CDSMSIapiFilterFilter: :ONPreprocHeaders(CHttpFilterContext* pCtxt, 
PHTTP_FILTER_PREPROC_HEADERS pHeaderlnfo) 

{ 

// TODO: React to this notification accordingly and 
// return the appropriate status code 

// Filter looks for the pattern "/avf ' and replaces the URL 

// with "/Servlet/DSMS_Servlet" (Will be modifiable using INI file) 

static const char strAppPathf] = "/avf; 

static const char strServletPath[] = "/Servlet/DSMS_Servlet"; 

char buffer[1024], *newURL; 
DWORD buffersize = sizeof(buffer); 
LVOID urlBuffer = pCtxt->AllocMem(1024); 

newURL = (char*) malloc(1024); 

pHeaderInfo->GetHeader (pCtxt->m_pFC, "url", buffer, &buffersize); 
char *pPos = strstr(buffer, strAppPath); 

// the URL should not include http://<server name> 
if (pPos) { 

strcpy( newURL, strServletPath ); 

strcat( newURL, pPos); 

pHeaderInfo->SetHeader (pCtxt->m_pFC, "url", newURL); 

} 

return SF_STATUS_REQ_NEXT_NOTIFICATION; 
} . 
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Steps 



Load Servlet properties from the properties file 




Read data from the HTTP request 

Create a hash table (name, value pairs) with parameters for the Filter Engine 
including HTTP headers, Content type, client IP address, HTTP method (GET 
and SET) and the actual data in the request 

Identify if the data has been signed. If not signed, call Filter Engine with the 
hash table 

If signed, URL decode the PKCS#7 message received from the Plug-In and 
insert it into the hash table 

Call the Filter Engine with the hash table 

Process the return value from the Filter Engine 

If the return value from the Filter Engine indicates that the web application has 
been called, then display the next page 

If the return value from the Filter Engine indicates that the page needs to be 
signed, the state of the Filter Engine is stored in a cookie and the page with the 
Plug-In is displayed 

If the return value from the Filter Engine indicates that the Client Certificate is 
GOOD, then change the State and send a request to Filter Engine to retrieve the 
next page. 

For all other values or exceptions, display error page to the client. 



#Sign request when user adds a new document to AltaVista 

BIModeSync; BISCertStatCheck; cookie, AltaVistaForum_AuthToken, dsmith; 

url, newDocForm 



#Sign request when user modifies a document in AltaVista 

BIModeSync; BISCertStatCheck; cookie, AltaVistaForum_AuthToken, dsmith; 

URL, modDocform 

#Sign request when user deletes a document from AltaVista 
BIModeSync; BISCertStatCheck; Cookie, AltaVistaForum_AuthToken, 
dsmith; url, delltemsForm 

#Test 

#BIModeSync; BISCertStatCheck;Iname,identrus;city,Boston 




NY2- 1114078.1 



package com.identrus.filterengine; 

import j ava.rmi . * ; 
import java.util.*; 
import com.identrus.util.*; 

/** 

This is an interface definition for the Filter Engine Server 
*/ 



public interface IRmiFEServer extends Remote { 
public ReturnObject Service (Hashtable table) 
throws RemoteException; 
} 
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Filter Engine Startup Steps 



Loads Filter Engine properties from the properties file 



Open log files 



Load SSL or Utility Certificates 



Load RMI server Policy File 



Load Rules files into the memory 



Validate Rules to verify correct formatting 



The Filter Engine Interface is now ready to receive requests 



Filter Engine Processing Steps 



Receives HTTP Request data and the State from the Servlet 
If the State passed from the Servlet is FE_NEW_REQUEST, the Filter Engine 
compares the request against the signing rules and determines whether the 
request has to be signed or not. It builds the Return Object specified in the 
FE_NEW_REQUEST State. 

If the State passed in from the Servlet is FE_SIGNED_DATA, then it calls the 
Bank Interface to check the status of the Certificate. After interacting with the 
Identrus network, the Bank Interface returns the status. The status and the data 
in the CMS message are put into a Return Object and sent to the Servlet 
If the State passed from the Servlet is FE_REQUEST_CHECKED, indicating 
the final stage of a signed transaction, the Web Application is called. The 
original page is retrieved from the Web Application and its content is returned 
to the Servlet in a Return Object 

Log all signed request to the event log and all errors to the error log 
All exceptions are returned to the Servlet as a part of the Return Object 
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Bank Interface Startup Steps 



Loads Bank Interface propert ies from the properties file 

Open log files 

Load SSL or Utility Certificates 

Load RMI s erver Policy File 

Load cryptographic modules, either software or hardware (Hardware Security 

Module API) as specified in the properties file 

At this stage the Bank Interfa ce is ready to receive service request 

Call Bank Interface service manager with the DSMS request that contains the 
name of the service, mode of the service and the message 
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Steps 



Retrieve Relying Customer and Root Certificate from the server 

Retrieve Subscribing Customer and Issuing Participant's Certificate from the 
CMS (Cryptographic Message Syntax) also referred as PKCS#7. 

Verify signature on the CMS message 

Verify signature on the Subscribing Customer's Certificate using the Issuing 
Participant's Certificate 

Verify signature on the Issuing Participant's Certificate using the Identrus Root 
Certificate that belongs to the Relying Participant 

The Validity period is then checked on the two Certificates received against the 
current date 

Retrieve the OCSP responder's URL from the Relying Customer's certificate 

Create an OCSP request for the Subscribing Customer's Certificate signed by 
the Relying Customer. All OCSP requests contain a Service Locator 
Extension, which is set by the Authority Information Access (AIA) extension 
defined in the certificate 

Log the OCSP request to the transaction log 

Create HTTP(S) connection to the OCSP responder and send the OCSP 
request. 

Receive OCSP response from the responder and verify the signature using the 
OCSP Responder's Certificate 

Get the status of the certificate from the Response 

Repeat steps 8 through 1 1 for the Issuing Participant and the Relying 
Participant's OCSP Responder's certificate 

Log the OCSP response to the transaction log 

If the status of all the responses are GOOD return GOOD, else return the status 

Log all signed request to the event log and all errors to the error log 

All exceptions are returned to the client as a part of the Return Object 



# 


Description 


Protocol 


1 


User clicks 'Submit' button on HTML Form in Web Browser 


HTML UI 


2 


Web Browser posts form data to SDK Web Server 


HTTP 


3 


SDK Web Server passes all requests to Servlet. 




4 


Servlet passes request to Filter Engine. 


RMI 


5 


Filter Engine creates a Return-to-Browser URL (as a GET with 
parameters for data) representing the data of the original POST or 
GET form posting and returns it along with instructions to get the 
data signed to the Servlet 


RMI 


6 


Servlet builds a response with 

1 . An Applet tag pointing to the Client Interface Applet OR 

2. A call to a browser plug-in and the arguments Return-to- 
Browser URL and the data to sign. 


Servlet 


7 


SDK Web Server returns the Servlet's response to the Web 
Browser. 


HTTP 


8 


Web Browser displays the HTML Page (requests the Applet if 
necessary) 


HTTP 


11 


Web browser displays Client Interface Applet or activates the 
plug-in, 

The arguments are the data to sign and possibly a URL 


Browser 


12 


User clicks button in to approve signing of form data. 


GUI 


13 


Client Interface (applet or plugin) calls Smart Card API to request 
that the Smart Card sign an SHA-1 hash of the form data. 


Client Interface 


15 


User enters PIN when driver ask for it. 


OS Dialog 


18 


Smart Card API returns signed form data to Client Interface. 


Client Interface 


19 


Client Interface makes a HTTP connection to the SD1( Web 
Server and submits the signed form data. 


HTTP 


20 


SDK Web Server passes request to Servlet 


Servlet 


21 


Servlet passes request to Filter Engine. 


RMI 


22 


Filter Engine calls Bank Interface with signed data. 


RMI 
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23 


The Bank Interface calls the Open Card API to request that the 
HSM sign an SHA-1 hash of the request to the bank. 


Java Function Call 


24 


Open Card API calls HSM OS Driver 


Java Native Call 


25 


HSM OS Driver calls HSM to perform signature. 


OS-Level Hardware 
Call 


26 


HSM OS Driver returns signed request to Open Card API 


Java Native Call 


27 


Open Card API returns signed request to Bank Interface 


Java Function Call 


28 


Bank Interface calls the relying party's bank. 


Warranty/Status 
Check 


29 


Relying party's bank calls the issuing party's bank. 


Warranty/OCSP 


30 


Issuing party's bank returns a signed response to the relying 
party's bank. 


Warranty/OCSP 


31 


Relying party's bank then calls the root. 


Warranty/OCSP 


32 


Root returns a signed response to the relying party's bank. 


Warranty/OCSP 


33 


Relying party's bank returns a signed response to the Bank 
Interface. 


Warranty/ Status 
Check 


34 


Bank Interface validates the signed data and then records the 
transaction in the log. 


File I/O 


35 


Bank Interface validates the signed data and then stores the 
signed data and the signed response from the relying party's bank 
into the SDK's database. 




36 


Bank Interface returns an OK or failure result to Filger Engine 


RMI 


37 


Filter Engine returns failure result to Servlet or passes on initial 
request to App Server. 


RMI 


38 


Serviet builds response indicating failure for SDK Web Server. 


Servlet 


39 


SDK Web Server returns servlet response to the browser if 
failure. 


HTTP 


45 


Web Application's Web Server calls the Web Application 


ISA 


46 


Web Application generates and returns its response. 


ISA 


47 


Web Application's Web Server returns the response to the Filter 
Engine 


HTTP 
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48 


Filter Engine returns response to Servlet. 


RMI 


49 


Servlet returns response to SDK Web Server 


Servlet 


50 


SDK Web Server returns response to Web Browser 


HTTP 
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Figure DSMS Active Integration 



# 


Description 


Protocol 


1 


User requests form that will require signing when submitted. 


HTML UI 


2 


Web Browser sends request to Web Server. 


HTTP 


3 


Web server forwards request to Web Application. 


ISA 


4 


Web Application returns an HTML page for the web server to 
return which references the Client Interface 


ISA 


5 


Web Server returns the HTML Page to Web Browser. 


HTTP 


6 


Web Browser requests Client Interface from Web Server. 


HTTP 


7 


Web Server retrieves Client Interface. 


OS File System 


8 


Web Server returns Client Interface. 


HTTP 


9 


User clicks the submit and sign button in the web page. 


HTML UI 


10 


Web Browser calls Client Interface. 


Client Interface 
Technology 


11 


Client Interface calls Windows PC/SC to have Smart Card sign 
data. 


OS API 


12 


User enters PIN. 


OS Dialog 


13 


Windows PC/SC calls Smart Card to sign data. 


OS -Level Hardware 
Call 


14 


Windows PC/SC returns signed data to Client Interface 


OS API 


15 


Client Interface returns signed data. 


Client Interface 
Technology 


16 


Web Browser posts signed data. 


HTTP 


17 


Web server passes signed posting to Web Application. 


ISA 


18 


Integration Code added to the Web Application calls the Bank 
Interface to verify the signature on the form. 


Bank Interface 
Technology 


19 


Bank Interface calls HSM OS Driver to sign request. 


OS-API 


20 


HSM OS Driver calls HSM to sign request. 


OS-Level Hardware 
Call 



Hft, ft 
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21 


HSM OS Driver returns signed request to Bank Interface 


OS-API 


22 


Bank Interface calls the Relying Party's Bank. 


Warranty/Status 


23 


Relying Party's Bank calls the Issuing Party's Bank. 


Warranty/OCSP 


24 


Issuing Party's Bank returns a signed response to the Relying 
Party's Bank. 


Warranty /OCSP 


25 


Relying Party's Bank calls the Root. 


Warranty/OCSP 


26 


Root returns signed response to Relying Party's Bank 


Warranty/OCSP 


27 


Relying Party's Bank returns signed response to the Bank 


Warrant/Status 


28 


Bank Interface stores the signed data and the signed OK response 
from the relying party's bank into the Signed Documents 
repository. 


Database-Access 
API 


29 


Bank Interface writes transaction log message. 


File I/O 


30 


Bank Interface returns result to Web Application. 


Bank Interface 
Technology 


31 


Web Application interprets the form post and returns the next 
page to the Web Server or an error. 


ISA 


32 


Web Server returns the page to the Web Browser. 


HTTP 



I 
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# Sample Servlet Properties File 

# The name of the RMI Server class file 
Servlet.fename=com.root.filterengine.RmiFEServer 

# The IP Address/URL of the Filter Engine's RMI Server 
Servlet.feip=rmi://10.1.20.163 



# Sample Filter Engine Properties File 

# The name of the RMI Server class file 
SERVER_NAME=com.root.filterengine.RmiFEServer 

# The IP Address/URL of the Filter Engine RMI Server 
IP_ADDRESS=10.1 .20. 163 

# Location of the Policy file 
POLICY_FILE=/dev/src/filterengine/policy 

# URL of the Web Application 
WEB_APP_URL=http://root8 .root.com 

# Location of the Rules file 
RULES_FILE=/root/rules/RulesFile.txt 

# The Name and Location of the Log File 
LOG_PATH-/root/logs/fe 

# Need'/' at end of CLASS_DIR 
CLASS_DIR=file:/root/ 

# The name of the RMI Server class file 
SSL_CERTS_DIRECTQRY=/root/sslcerts 




n 
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# Sample Bank Interface Properties File -- Log file Path & type (Flat/DB) 

LOG_PATH=/root/logs/bi 

LOG_TYPE=TRANS_DB 

#LOG_TYPE=TRANS_FILE 



# Relying Customer Certificate/Private Key for Software Engine 
REQUEST_CERT=/root/certs/RelyingCustomer.crt 
REQUEST J?RIVJCEY=/root/certs/PrivateKey.pvk 

# Root Certificate for Software Engine 
ROOT_CERT=/root/certs/Root.crt 

# Specify the RMI Server Name/IP address 
SERVER_NAME=com.root.bankinterface,RmiBIServer 
IP_ADDRESS=rootl 1. root.com 

# Banklnterface policy file 
POLICY JFILE=/root/policies/bipolicy 

# CSP Responder URL and SSL 

RESPONDER_URL=https://testlab8.qa.valicert.com:90/ 

# Need V at end of CLASS_DIR 
CLASS_DIR=file:/root/ 

#IssuingBank Certificate. Only for test until we get new SmartCards 
DEBUG=/root/certs/IssuingBank.crt 

#Directory of trusted CA Certificates for SSL. 
SSL_CERTS_DIRECTORY=/root/sslcerts/ 



5 



# Cryptographic Engine Type/Log File 
#HSM_TYPE=com.root.hsm.HSMCryptoPKCS 1 1 
HSM_TYPE=com.root.hsm.HSMCryptoSoftware 
HSM_LOG_FILE=/root/logs/hsm.log 
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2 1 094), Jonathan A. Marshall (Reg. No. 24614), Barry D. Rein (Reg. No. 224 1 1 ), Stanton T. Lawrence, III (Reg. No. 25736), Charles E. McKenney (Reg. No. 22795), 
Philip T. Shannon (Reg. No. 24278), Francis E. Morris (Reg.No. 2461 5),CharlesE. Miller (Reg. No. 24576), Gidon D. Stern (Reg. No. 27469), John J. Lauter, Jr (Reg. 
No. 278 14), Brian M. Poissant(Reg.No. 28462),Brian D. Coggio (Reg. No. 27624), Rory J. Radding (Reg. No. 28749), Stephen J. Harbulak (Reg. No. 291 66), Donald 
J. Goodell (Reg. No. 19766), James N. Palik (Reg. No. 255 10), Thomas E. Friebel (Reg. No. 29258), Laura A. Coruzzi (Reg. No. 30742), Jennifer Gordon (Reg. No. 
30753), AllanA.Fanucci(Reg.No.30256),GeraldineF. Baldwin (Reg.No. 31232), VictorN.Balancia (Reg. No. 31231), Samuel B.Abrams (Reg. No. 30605), Steven 
I. Wallach (Reg. No 35402), Marcia H. Sundeen (Reg. No. 30893), Paul J. Zegger (Reg. No. 33821), Edmond R. Bannon (Reg. No. 32 110), Bruce J. Barker (Reg. 
No. 33291), Adriane M. Antler (Reg. No. 32605), Thomas G. Rowan (Reg. No. 34419), James G. Markey (Reg. No. 3 1636), Thomas D. Kohler (Reg. No. 32797), 
Scott D. Stimpson (Reg. No. 33607), Gary S. Williams (Reg. No. 3 1 066), William S. Galliani (Reg. No. 33885), Ann L. Gisolfi (Reg. No. 3 1 956), Todd A. Wagner 
(Reg. No. 3 5399), Scott B. Familant (Reg. No. 355 14), Kelly D. Talcott (Reg. No. 39582), Francis D. Cerrito (Reg. No.3 8 1 00), Anthony M. Insogna(Reg. No. 35203), 
Brian M. Rothery (Reg. No. 35340), Brian D. Siff(Reg.No. 35679), and Alan Tenenbaum (Reg. No. 34939), all ofPennie & Edmonds LLP, whose addresses are 1 1 55 
Avenue of the Americas, New York, New York 10036, 1667 K Street N.W., Washington, DC 20006 and 3300 Hillview Avenue, Palo Alto, CA 94304, and each of 
them, my attorneys, to prosecute this application, and to transact all business in the Patent and Trademark Office connected therewith. 
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I hereby declarethatall statements made herein of my own knowledge are true and that all statements made on information and belief are believed to be true; and further 
that these statements were made with the knowledge that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false statements may jeopardize the validity of the application or any patent issuing thereon. 
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